Das zu lösende Problem¶

Die Übersetzung von Dokumentation ist an sich nicht sehr schwierig. Texte sind deutlich länger als Programmmeldungen und die Übersetzung dauert daher länger, allerdings werden dazu keine besonderen Fähigkeiten benötigt. Die Schwierigkeit liegt im Warten der Übersetzungsarbeit. Es ist sehr schwierig, fehleranfällig und unangenehm, herauszufinden, welche Teile sich geändert haben und aktualisiert werden müssen. Ich denke, das erklärt, warum so viele übersetzte Dokumentation da draußen veraltet ist.

Die Antworten von Po4a¶

Daher besteht der ganze Sinn von Po4a darin, die Dokumentationsübersetzungen wartbar zu halten. Die Idee ist, die Gettext-Methodologie für dieses neue Feld zu nutzen. Wie bei Gettext werden Texte aus ihren ursprünglichen Stellen herausgelöst, um in einem einheitlichen Format den Übersetzern präsentiert zu werden. Die klassischen Gettext-Werkzeuge helfen dann beim Aktualisieren ihrer Arbeiten, wenn eine neue Veröffentlichung des Originals herauskommt. Im Gegensatz zu klassichen Gettext-Model werden die Übersetzungen dann wieder in die Struktur des ursprünglichen Dokuments eingefügt, so dass es wie die ursprüngliche (englische) Version verarbeitet und verteilt werden kann.

Daher wird die Ermittlung der zu geänderten (und daher zu aktualisierenden) Teile des Dokuments sehr leicht. Ein andere Pluspunkt liegt darin, dass die Werkzeuge fast die gesamte Arbeit übernehmen, wenn die Struktur des Originals fundamental neu organisiert wird und wenn Kapitel herumgeschoben, zusammengefasst oder geteilt werden. Indem der zu übersetzende Text aus der Dokumentenstruktur herausgelöst wird, hält dies Sie auch von der Komplexität der Textformatierung fort und reduziert das Risiko, dass Sie ein defektes Dokument erhalten (selbst wenn das nicht vollständig verhindert wird).

Bitte lesen Sie auch die FAQ weiter unten in diesem Dokument für eine komplette Liste der Vor- und Nachteile dieser Vorgehensweise.

Unterstützte Formate¶

Zur Zeit wurde diese Vorgehensweise erfolgreich für mehrere Arten von Textformatierungsformaten umgesetzt:

man

Das gute alte Handbuchformat, verwandt von vielen Programmen da draußen. Die Unterstützung durch Po4a wird hier sehr begrüßt, da dieses Format etwas schwierig zu benutzen und für Neulinge nicht wirklich einladend ist. Das Modul Locale::Po4a::Man(3pm) unterstütz das Format »mdoc«, das von den BSD-Handbuchseiten verwandt wird (diese sind auch unter Linux recht häufig anzutreffen).

pod

Das ist das »Perl Online Documentation«-Format. Die Sprache und Erweiterungen selbiger sind auf diese Art dokumentiert sowie die meisten existierenden Perl-Skripte. Sie erleichtert es, die Dokumentation nahe beim eigentlichen Code zu halten, indem beide in die gleiche Datei eingebettet werden. Es erleichtert Programmierern die Arbeit, aber unglücklicherweise nicht den Übersetzern.

sgml

Obwohl dieses Format heutzutage etwas von XML verdrängt wurde, wird es noch recht oft für Dokumente verwandt, die mehr als ein paar Bildschirmseiten lang sind. Es ermöglicht es Ihnen, komplette Bücher zu erstellen. Die Übersetzung so langer Dokumente zu aktualisieren kann zu einem echten Alptraum werden. diff stellt sich oft als nutzlos raus, wenn der ursprüngliche Text nach der Aktualisierung neu eingerückt wurde. Glücklicherweise kann Ihnen Po4a bei diesem Prozess helfen.

Derzeit werden nur die DebianDoc- und DocBook-DTD unterstützt, aber das Hinzufügen einer Unterstützung für eine neue DTD ist wirklich leicht. Es ist sogar möglich, Po4a für eine unbekannte SGML-DTD zu verwenden, ohne den Code zu verändern, indem die benötigten Informationen auf der Befehlszeile übergeben werden. Lesen Sie Locale::Po4a::Sgml(3pm) für weitere Details.

TeX / LaTeX

Das LaTeX-Format ist ein wichtiges Dokumentationsformat, das in der Welt der Freien Software und für Veröffentlichungen genutzt wird. Das Modul Locale::Po4a::LaTeX(3pm) wurde mit der Python-Dokumentation, einem Buch und ein paar Präsentationen ausprobiert.

Texinfo

Die gesamte GNU-Dokumentation ist in diesem Format geschrieben (das ist sogar eine der Voraussetzungen, um ein offizielles GNU-Projekt zu werden). Die Unterstützung für Locale::Po4a::Texinfo(3pm) in Po4a ist noch ganz am Anfang. Bitte berichten Sie Fehler und Funktionalitätswünsche.

xml

Das XML-Format liegt vielen Dokumentationsformaten zu Grunde.

Derzeit wird die DocBook-DTD von Po4a unterstützt. Lesen Sie Locale::Po4a::Docbook(3pm) für weitere Details.

andere

Po4a kann auch mit einigen selteneren oder spezialisierten Formaten umgehen, wie dem Dokumentationsformat der Kompilierungsoptionen des 2.4.x-er Kernels oder der vom Dia-Werkzeug erstellten Diagramme. Das Hinzufügen eines neuen Formats ist oft sehr leicht und die Hauptaufgabe besteht darin, einen Parser für Ihr Zielformat zu entwickeln. Lesen SIe Locale::Po4a::TransTractor(3pm) für mehr Informationen dazu.

Nicht unterstützte Formate¶

Unglücklicherweise fehlen Po4a noch Unterstützung für einige Dokumentationsformate.

Es gibt einen ganzen Satz an weiteren Formaten, die wir gerne mit Po4a unterstützen würden, nicht nur Dokumentationsformate. Tatsächlich würden wir gerne alle Marktnischen besetzen, die von den klassichen Gettext-Werkzeugen übriggeblieben sind. Darunter fallen Paketbeschreibungen (Deb und RPM), Paketinstallationsskriptfragen, Paket-Änderungsprotokolle (»Changelogs«) und alle spezialisierten Dateiformate, die von Programmen verwandt werden, wie Spieleszenarien oder WINE-Ressource-Dateien.

Graphischer Überblick¶

Das folgende Schema gibt einen Überblick über den Prozess der Dokumentationsübersetzung mittels Po4a. Haben Sie keine Angst vor der scheinbaren Komplexität, dies kommt daher, das hier der gesamte Prozess dargestellt ist. Sobald Sie Ihr Projekt auf Po4a umgestellt haben, ist nur der rechte Teil der Graphik relevant.

Beachten Sie, dass Master.dok als Beispiel der zu übersetzenden Dokumentation dient und Übersetzung.dok der entsprechende übersetzte Text ist. Die Endung könnte .pod, .xml oder .sgml lauten, abhängig vom Format. Jeder Teil der Abbildung wird in den folgenden Abschnitten noch im Detail dargestellt.

                                   Master.dok
                                       |
                                       V
     +<-----<----+<-----<-----<--------+------->-------->-------+
     :           |                     |                        :
{Übersetzung}    |     { Aktualisierung von Master.dok }        :
     :           |                     |                        :
   XX.dok        |                     V                        V
(optional)       |                 Master.dok ->-------->------>+
     :           |                   (neu)                      |
     V           V                     |                        |
  [po4a-gettextize]   dok.XX.po--->+   |                        |
          |            (alt)       |   |                        |
          |              ^         V   V                        |
          |              |     [po4a-updatepo]                  |
          V              |           |                          V
   Übersetzung.pot       ^           V                          |
          |              |         dok.XX.po                    |
          |              |        (unscharf)                    |
   { Übersetzung }       |           |                          |
          |              ^           V                          V
          |              |  {manuelle Bearbeitung}              |
          |              |           |                          |
          V              |           V                          V
      dok.XX.po --->---->+<---<---- doc.XX.po   Addendum     Master.dok
    (anfänglich)                   (aktuell)   (optional)     (aktuell) 
          :                          |            |             |
          :                          V            |             |
          +----->----->----->------> +            |             |
                                     |            |             |
                                     V            V             V
                                     +------>-----+------<------+
                                                  |
                                                  V
                                           [po4a-translate]
                                                  |
                                                  V
                                                XX.dok
                                              (aktuell)

Auf der linken Seite wird gezeigt, wie eine Übersetzung, die Po4a nicht verwendet, in dieses System erfolgt. Oben im rechten Teil werden die Tätigkeiten des ursprünglichen Autors dargestellt (Aktualisierung der Dokumentation). In der Mitte vom rechten Teil sind die automatischen Tätigkeiten von Po4a dargestellt. Das neue Material wird herausgelöst und mit der existierenden Übersetzung verglichen. Unveränderte Teile werden gefunden und vorherige Übersetzungen verwandt. Teile, die teilweise geändert wurden, werden auch mit der vorheriegen Übersetzung verbunden, allerdings mit einer speziellen Markierung, die angibt, dass die Übersetzung aktualisiert werden muss. Der untere Teil der Abbildung zeigt, wie formatierte Dokumente gebaut werden.

Tatsächlich ist der einzige manuelle Arbeitsschritt, den Sie als Übersetzer durchführen müssen, die Bearbeitung der mit »{manual editing}« markierten Bereiche. Jaja, es tut mir leid, Po4a hilft beim Übersetzen. Es übersetzt nichts für Sie …

HOWTO: Wie wird eine neue Übersetzung begonnen?¶

Dieser Abschnitt stellt die benötigten Schritte dar, um eine neue Übersetzung mit Po4a zu beginnen. Die Verfeinerungen, um ein existierende Projekt in dieses System zu überführen, werden in den relevanten Abschnitten dargestellt.

Um eine neue Übersetzung mit Po4a anzufangen, müssen Sie die folgenden Schritte ausführen:

• Herauslösen des zu übersetzenden Texts aus dem ursprünglichen Dokument <Master.dok> in eine neue Übersetzungsvorlagendatei <Übersetzung.pot> (dem Gettext-Format). Verwenden Sie dafür das Programm po4a-gettextize auf folgende Art und Weise:

    $ po4a-gettextize -f <Format> -m <Master.dok> -p <Übersetzung.pot>
      

  <Format> ist natürlich das im Dokument Master.dok verwandte Format. Wie erwartet, geht die Ausgabe in translation.pot. Bitte lesen Sie po4a-gettextize(1) für weitere Details über die existierenden Optionen.

• Übersetzen Sie tatsächlich, was übersetzt werden soll. Dafür müssen Sie die POT-Datei in z.B. dok.XX.po umbenennen (wobei XX der ISO639-Code für die Sprache ist, in die Sie übersetzen, z.B. fre) und bearbeiten Sie die entstandene Datei. Oft ist es eine gute Idee, die Datei nicht XX.po zu nennen, um Verwirrung mit der Übersetzung der Programmmeldungen zu vermeiden, allerdings ist das Ihre Entscheidung. Vergessen Sie nicht, die Kopfzeilen der PO-Datei zu aktualisieren, sie sind wichtig.

  Die eigentliche Übersetzung kann mit dem PO-Modus von Emacs oder Vi, Lokalize (KDE-basiert), Gtranslator (GNOME-basiert) oder mit welchem Programm Sie am liebsten arbeiten (z.B. Virtaal), erfolgen.

  Wenn Sie mehr darüber wissen wollen, müssen Sie auf jeden Fall die Gettext-Dokumentation konsultieren. Sie ist im Paket gettext-doc verfügbar.

HOWTO: Wie wird die Übersetzung zurück in eine Dokumentationsdatei zurücküberführt?¶

Sobald Sie mit der Übersetzung fertig sind, möchten Sie die übersetzte Dokumentation erhalten und diese dann zusammen mit der ursprünglichen an die Benutzer verteilen. Verwenden Sie hierfür das Programm po4a-translate(1) wie folgt (wobei XX für den Sprachcode steht):

  $ po4a-translate -f <Format> -m <Master.dok> -p <dok.XX.po> -l <XX.dok>

Wie vorher ist <format> das im Dokument Master.dok verwandte Format. Diesmal ist aber die mit dem Schalter -p übergebene PO-Datei Teil der Eingabe. Dies ist Ihre Übersetzung. Die Ausgabe landet in XX.dok.

Bitte lesen Sie po4a-translate(1) für weitere Details.

HOWTO: Wie wird eine Po4a-Übersetzung aktualisiert?¶

Um Ihre Übersetzung zu aktualisieren, wenn sich die ursprüngliche Datei Master.dok geändert hat, verwenden Sie das Programm po4a-updatepo(1) wie folgt:

  $ po4a-updatepo -f <Format> -m <neue_Master.dok> -p <alte_dok.XX.po>

(Bitte lesen Sie po4a-updatepo(1) für weitere Details.)

Natürlich wird der neue Absatz in dem Dokument nicht magisch in der PO-Datei durch diesen Befehl übersetzt werden und Sie müssen die PO-Datei manuell aktualisieren. Entsprechend müssen Sie die Übersetzung für Absätze, die geändert wurden, anpassen. Um sicherzustellen, dass Sie keine verpassen werden diese beim Erstellen mit »fuzzy« markiert und Sie müssen diese Markierung entfernen, bevor die Übersetzung von po4a-translate verwandt werden kann. Wie bei der ursprünglichen Übersetzung verwenden Sie am besten Ihren Lieblings-PO-Editor hierfür.

Sobald Ihre PO-Datei wieder aktuell ist, ohne verbliebene unübersetzte oder unscharfe Zeichenketten, können Sie ein übersetztes Dokument erstellen, wie dies im vorherigen Abschnitt beschrieben wurde.

HOWTO: Wie wird eine existierende Übersetzung nach Po4a konvertiert?¶

Oft haben Sie ein Dokument manuell übersetzt, bis eine größere Reorganisation des ursprünglichen Dokuments Master.dok stattfand. Nach ein par unschönen Versuchen mit diff und ähnlichen Werkzeugen möchten Sie auf Po4a umstellen. Allerdings möchten Sie natürlich nicht ihre bestehenden Übersetzungen dabei verlieren. Keine Angst, dieser Fall wird auch von den Po4a-Werkzeugen abgedeckt und wird »Gettextisierung« genannt.

Der Schlüssel ist dabei, dass die gleiche Struktur im übersetzten Dokument und in dem ursprünglichen vorliegt, so dass die Werkzeuge die zugehörigen Inhalte entsprechend ermitteln können.

Falls Sie Glück haben (d.h. falls die Struktur beider Dokumente perfekt passt) wird dies reibungsfrei verlaufen und Sie sind in wenigen Sekunden eingerichtet. Andernfalls werden Sie herausfinden, warum dieser Prozess so einen scheußlichen Namen hat und Sie bereiten sich auf Routinearbeit vor. Denken Sie in jedem Fall daran, dass dies der Preis ist, den Sie zahlen müssen, um den Komfort von Po4a danach zu genießen. Das gute daran ist, dass Sie diesen Prozess nur einmal durchführen müssen.

Ich kann das nicht oft genug wiederholen. Um den Prozess zu erleichtern, ist es daher wichtig, dass Sie die genau identische Version finden, die zur Übersetzung verwandt wurde. Am besten ist es, wenn Sie sich die VCS-Revision, die für die Übersetzung verwandt wurde, notiert hatten und Sie sie nicht im Übersetzungsprozess geändert haben, und Sie diese daher verwenden können.

Es wird nicht gut funktionieren, wenn Sie einen aktualisierten Originaltext mit der alten Übersetzung verwenden. Es bleibt möglich, aber es ist schwieriger und sollte wirklich vermieden werden, wenn möglich. Tatsächlich schlage ich vor, dass die beste Lösung, wenn Sie den ursprünglichen Text nicht wiederfinden können, ist, jemanden zu finden, der die Gettextisierung für Sie vornimmt (aber nicht mich ;).

Vielleicht bin ich hier zu dramatisch. Selbst wenn Dinge schiefgehen, bleibt dies deutlich schneller als eine komplette Neuübersetzung. Ich konnte die existierende französische Übersetzung der Perl-Dokumentation an einem Tag gettextisieren, selbst obwohl Dinge schief gegangen sind. Das waren mehr als zwei Megabyte an Text und eine neue Übersetzung hätte Monate oder mehr gedauert.

Lassen Sie mich zuerst die Grundlagen der Prozedur erläutern. Später werde ich dann Tipps für die Fälle geben, bei denen was schief läuft. Um das Verständnis zu erleichtern, verwende ich das obige Beispiel noch mal.

Sobald Sie Sie die alte Master.dok, die auf die Übersetzung XX.dok passt, haben, kann die Gettextisierung direkt mit der PO-Datei dok.XX.po erfolgen, ohne die manuelle Übersetzung der Datei Übersetzung.pot:

 $ po4a-gettextize -f <Format> -m <alte_Master.dok> -l <XX.dok> -p <dok.XX.po>

Wenn Sie Glück haben, wars das. Sie haben Ihre alte Übersetzung nach Po4a konvertiert und können mit der Aktualisierung sofort beginnen. Folgen Sie einfach den Anweisungen, wie sie einige Abschnitte weiter oben beschrieben wurden, um Ihre PO-Datei mit dem neusten Originaldokument zu synchronisieren, und aktualisieren Sie die Übersetzung entsprechend.

Beachten Sie, dass selbst wenn alles korrekt abgelaufen zu sein scheint, es immer noch Fehlermöglichkeiten gibt. Das liegt daran, dass Po4a nicht in der Lage ist, den Text zu verstehen, um sicherzustellen, dass die Übersetzung auf das Original passt. Daher werden alle Zeichenketten bei diesem Vorgang mit »fuzzy« (d.h. als unscharf) markiert. Sie sollten daher alle sorgfältig prüfen, bevor Sie diese Markierung entfernen.

Oft passen die Dokumentstrukturen nicht genau, wodurch po4a-gettextize daran gehindert wird, seine Aufgabe korrekt wahrzunehmen. Zu diesem Zeitpunkt besteht das Spiel darin, die Dateien zu bearbeiten, um ihre verdammte Struktur passend zu bekommen.

Es kann helfen, den Abschnitt Gettextization: Wie funktioniert es? unten zu lesen. Ein Verständnis des internen Vorgangs wird Ihnen bei der Durchführung helfen. Gut daran ist, dass po4a-gettextize recht ausführlich berichtet, was schief gelaufen ist, wenn das passiert. Zuerst nagelt es den Punkt fest, bei dem in den Dokumenten die Strukturdiskrepanzen vorliegen. Sie werden die Zeichenketten kennenlernen, die nicht zueinander passen, ihre Position im Text und ihren Typ. Desweiteren wird die soweit generierte PO-Datei in gettextization.failed.po ausgegeben.

• Entfernen Sie alle zusätzlichen Teile in der Übersetzung, wie den Abschnitt, in dem Sie den Namen des Übersetzers angeben und allen Danekn, die zu der Übersetzung beigetragen haben. Adenda, die im nächsten Abschnitt beschrieben werden, erlauben es Ihnen, diese Informationen wieder hinzuzufügen.
• Haben Sie keine Scheu, sowohl das Original als auch die Übersetzung zu bearbeiten. Das wichtigste ist, die PO-Datei zu erhalten. Sie können diese dann im Anschluss aktualisieren. Andererseits sollte die Bearbeitung der Übersetzung vorgezogen werden, wenn beide möglich wären, da dies die Dinge erleichtert, wenn die Gettextisierung abgeschlossen ist.
• Falls notwendig, löschen Sie Teile des Originals, falls diese nicht übersetzt wurden. Beim anschließenden Synchronisieren der PO-Datei mit dem Dokument kommen diese von alleine zurück.
• Falls Sie die Struktur etwas geändert haben (um zwei Absätze zusammenzufassen oder einen anderen aufzuteilen) nehmen Sie diese Änderungen zurück. Falls es Probleme im Original gibt, sollten Sie den Originalautor informieren. Wenn Sie diese nur in Ihrer Übersetzung korrigieren, werden diese nur für einen Teil der Gemeinschaft korrigiert. Und desweiteren ist das unmöglich, wenn Sie Po4a verwenden ;)
• Manchmal passen die Inhalte des Absatzes, aber ihr Typ nicht. Dies zu korrigieren hängt stark vom Format ab. In POD und Man kommt dies oft daher, dass bei einem der beiden eine Zeile enthalten ist, die mit einem Leerzeichen beginnt. In diesen Formaten kann so ein Absatz nicht umgebrochen werden und erhält daher einen anderen Typ. Entfernen Sie einfach das Leerzeichen und es klappt wieder. Es kann sich auch um einen Tippfehler im Namen der Markierung (Tags) handeln.

  Entsprechend könnten zwei Absätze in POD zusammengefasst worden sein, wenn die trennende Zeile Leerzeichen enthält oder wenn es keine Leerzeile vor der =item-Zeile und vor dem Inhalt des »item«s gibt.

• Manchmal sind die Dateien nicht mehr synchron und die Übersetzuzng hängt am falschen Absatz. Dies zeigt an, dass das echte Problem schon früher in den Dateien vorlag. Überprüfen Sie gettextization.failed.po, um herauszufinden, wo die Desynchronisation beginnt und korrigieren Sie dies dort.
• Manchmal erhalten Sie das starke Gefühl, dass Po4a Teile des Texts aufgefuttert hat, entweder vom Original oder von der Übersetzung. gettextization.failed.po können Sie entnehmen, dass beide gut aufeinander gepasst haben und dann Schlug die Gettextisierung fehl, da versucht wurde, einen Absatz mit einem Absatz vor (oder hinter) dem Richtigen zu paaren, als ob der richtige Absatz verschwunden wäre. Verfluchen Sie Po4a wie ich es getan habe, als es mir das erste Mal passierte. Gründlich.

  Diese unglückliche Situation entsteht, wenn ein Absatz mehrfach im Dokument vorkommt. In diesem Fall wird kein neuer Eintrag in der PO-Datei erstellt, sondern es wird stattdessen eine neue Referenz zu dem bestehenden hinzugefügt.

  Wenn daher der gleiche Absatz zwei Mal im Original auftaucht, aber nicht jedes Mal exakt identisch übersetzt wurde, bekommen Sie den Eindruck, dass ein Absatz des Originals verschwunden ist. Entfernen Sie einfach die neue Übersetzung. Falls Sie bevorzugen, stattdessen die erste Übersetzung zu entfernen, da sie einfach besser war, entfernen Sie die zweite Übersetzung von der Stelle, an der sie war, und stellen sie an die Stelle der ersten.

  Wurden im Gegensatz dazu zwei ähnliche, aber verschiedene Absätze exakt identisch übersetzt, bekommen Sie den Eindruck, dass ein Absatz der Übersetzung verschwunden ist. Eine Lösung ist, ein dumme Zeichenkette zum ursprünglichen Abstz hinzuzufügen (wie »Ich bin anders«). Haben Sie keine Angst, diese Dinge verschwinden während der Synchronisation, und wenn der hinzugefügte Text kurz genug ist, wird Gettext ihre Übersetzung zum existierenden Text hinzufügen (und sie dabei als unscharf (»fuzzy«) markieren, was hier allerdings irrelevant ist, da alle Zeichenketten nach der Gettextisierung unscharf sind).

Hoffentlich werden diese Tipps Ihnen bei der Gettextisierungsarbeit und der Erlangung der wertvollen PO-Datei helfen. Sie können jetzt Ihre Datei synchronisieren und mit der Übersetzung beginnen. Bitte beachten Sie, dass bei langen Texten die erste Synchronisierung sehr lange dauert.

Beispielsweise dauerte der erste Lauf von po4a-updatepo der französischen Übersetzung der Perl-Dokumentation (eine 5.5 MB PO-Datei) rund zwei Tage auf einem 1 GHz G5-Computer. Ja, 48 Stunden. Die folgenden dauern aber nur ein paar Dutzend Sekunden auf meinem alten Laptop. Dies kommt daher, dass beim ersten Lauf die meisten Msgids der PO-Datei auf keine der POT-Datei passen. Dies zwingt Gettext, die ähnlichsten mit einem sehr aufwändigen Zeichenketten-Approximier-Algorithmus zu suchen.

HOWTO: Wie wird zusätzlicher Text zu Übersetzungen (wie der Name des Übersetzers) hinzugefügt?¶

Aufgrund der Gettext-Methode ist dies schwieriger mit Po4a als das vorherige reine Bearbeiten einer neuen Datei neben der ursprünglichen. Allerdings bleibt es dank sogenannter addenda möglich.

Es mag beim Verständnis helfen, Addenda als eine Art von Patches, die auf das übersetzte Dokument nach der Verarbeitung angewandt werden, zu betrachten. Sie unterscheiden sich recht stark von gewöhnlichen Patches (es gibt nur eine Zeile Kontext, der reguläre Ausdrücke von Perl einbetten kann, uns sie können nur neuen Text hinzufügen ohne alten zu löschen), aber die Funktionalität ist die gleiche.

Ihr Ziel ist es, dem Übersetzer zu erlauben, zusätzliche Inhalte zum Dokument hinzuzufügen, der keine Übersetzung aus dem ursprünglichen Dokument ist. Am häufigsten wird dies dazu verwandt, einen Abschnitt über die Übersetzung selbst hinzuzufügen, in der Beitragende aufgeführt sind und dargestellt wird, wie ein Fehler in der Übersetzung gemeldet werden soll.

Ein Addendum muss als separate Datei bereitgestellt werden. Die erste Zeile stellt eine Kopfzeile dar, die anzeigt, wo in dem erstellten Dokument das Addendum eingefügt werden soll. Der Rest der Addendumdatei wird dann unverändert an der angegebenen Position des erstellten Dokuments hinzugefügt.

Die Kopfzeile hat eine recht starre Syntax: Sie muss mit der Zeichenkette PO4A-HEADER: beginnen, gefolgt von einer durch Semikola (;) getrennten Liste von Schlüssel=Wert-Feldern. Leerzeichen SIND wichtig. Beachten Sie, dass Sie das Semikolon-Zeichen (;) nicht im Wert benutzen können (hierbei hilft auch nicht, das Zeichen zu schützen).

Das klingt wieder beängstigend, aber das Beispiel unten sollte Ihnen dabei helfen, herauszufinden, wie die von Ihnen benötigte Kopfzeile geschrieben wird. Um die Diskussion zu beleuchten, nehmen wir an, dass Sie einen Abschnitt »Über diese Übersetzung« nach dem Abschnitt »Über dieses Dokument« hinzufügen möchten.

Dies sind die möglichen Schlüssel in der Kopfzeile:

position (zwingend)

Ein regulärer Ausdruck. Das Addendum wird in der Nähe der Zeile platziert, die auf diesen regulären Ausdruck passt. Beachten Sie, dass wir hier vom übersetzten Dokument reden, nicht dem ursprünglichen. Falls mehr als eine Zeile (oder keine) auf diesen regulären Ausdruck passt, wird das Hinzufügen fehlschlagen. Es ist in der Tat besser, einen Fehler zu melden, als das Addendum an der falschen Stelle hinzuzufügen.

Diese Zeile wird im Folgenden Positionspunkt genannt. Der Punkt, an dem das Addendum hinzugefügt wird, wird Einfügepunkt genannt. Diese zwei Punkte sind in der Nähe voneinander, aber nicht identisch. Wenn Sie beispielsweise einen neuen Abschnitt einfügen wollen, ist es leichter, den Positionspunkt auf den Titel des vorhergehenden Abschnitts zu setzen und Po4a zu erklären, wo der Abschnitt endet (denken Sie daran, dass der Positionspunkt durch einen regulären Ausdruck beschrieben wird, der auf eine eindeutige Zeile passen sollte).

Die Positionierung des Einfügepunkts in Hinblick auf den Positionspunkt wird durch die Felder mode, beginboundary und endboundary gesteuert, die unten beschrieben sind.

In unserem Fall hätten wir:

     position=<title>Über dieses Dokument</title>
    

mode (zwingend)

Dies kann entweder die Zeichenkette before (vor) oder after (nach) sein, die die Position des Addendums relativ zum Positionspunkt beschreibt.

Da wir möchten, dass der neue Abschnitt unterhalb desjenigen, auf den der reguläre Ausdruck passt, eingefügt wird:

     mode=after
    

beginboundary (nur bei mode=after verwandt, in diesem Fall zwingend)

endboundary (dasselbe)

regulärer Ausdruck, der zum Ende des Abschnitts passt, hinter dem das Addendum folgt

Wenn mode=after ist, ist der Einfügepunkt hinter dem Positionspunkt, aber nicht direkt dahinter! Er wird ans Ende des Abschnitts platziert, der beim Positionspunkt anfängt, d.h. hinter oder vor der Zeile, auf die das Argument ???boundary passt, abhängig davon, ob Sie beginboundary oder endboundary verwandt haben.

In diesem Fall kann ausgewählt werden, das Ende des Abschnitts anzugeben, das beim Hinzufügen von Folgendem passt:

   endboundary=</Abschnitt>
    

oder den Anfang des nächsten Abschnitts anzugeben, indem Folgendes angegeben wird:

   beginboundary=<Abschnitt>
    

In beiden Fällen wird das Addendum nach dem </Abschnitt> und vor dem <Abschnitt> platziert. Die erste Variante ist besser, da sie auch funktioniert, wenn das Dokument neu organisiert wird.

Es gibt beide Formen, da sich die Formate der Dokumentationen unterscheiden. In einigen davon gibt es eine Möglichkeit, das Ende eines Abschnitts zu markieren (genauso wie im gerade benutzten </Abschnitt>), während einige andere das Ende des Abschnitts nicht explizit markieren (wie in Handbuchseiten). Im erstgenannten Fall möchten Sie keine Abschnittsgrenzen, die ans Ende eines Abschnitts passen, so dass der Einfügepunkt danach kommt. Im letztgenannten Fall möchten Sie erreichen, dass Abschnittsgrenzen an den Anfang des nächsten Abschnitts passen, so dass der Einfügepunkt direkt davor kommt.

Dies kann undurchsichtig erscheinen, aber die nächsten Beispiele werden Sie hoffentlich erleuchten.

Um das bisher benutzte Beispiel zusammenzufassen, können Sie, um einen Abschnitt namens »Über diese Übersetzung« nach dem »Über dieses Dokument« einem SGML-Dokument hinzuzufügen, eine dieser beiden Kopfzeilen verwenden:

 PO4A-HEADER: mode=after; position=Über dieses Dokument; endboundary=</section>
 PO4A-HEADER: mode=after; position=Über dieses Dokument; beginboundary=<section>
    

Falls Sie etwas hinter den folgenden Nroff-Abschnitt hinzugefügen möchten:

  .SH "AUTOREN"
    

Sie sollten eine Position setzen, die auf diese Zeile passt und ein beginboundary, das auf den Anfang des nächsten Abschnitts (d.h. ^\.SH) passt. Das Addendum wird dann nach dem Positionspunkt und unmittelbar vor der ersten Zeile, die auf das beginboundary passt, hinzugefügt. Das heißt:

 PO4A-HEADER:mode=after;position=AUTOREN;beginboundary=\.SH
    

Falls Sie einem Abschnitt etwas hinzugefügen möchten (etwa hinter »Copyright Großer Kerl«), statt einen ganzen Abschnitt hinzuzufügen, geben Sie eine Position an, die zu dieser Zeile passt und geben Sie ein beginboundary an, das zu irgendeiner Zeile passt.

 PO4A-HEADER:mode=after;position=Copyright Großer Kerl, 2004;beginboundary=^
    

Falls Sie am Ende des Dokuments etwas hinzufügen möchten, geben Sie eine Position an, die zu einer Zeile Ihres Dokuments passt (aber nur eine Zeile – Po4a wird nicht fortfahren, wenn sie nicht eindeutig ist) und geben Sie ein endboundary an, das zu nichts passt. Verwenden Sie hier keine einfachen Zeichenketten wie »EOF«, aber nehmen Sie bevorzugt solche, bei denen es unwahrscheinlich ist, dass sie sich in Ihrem Dokument befinden.

 PO4A-HEADER:mode=after;position=<title>Über</title>;beginboundary=FakePo4aBoundary
    

Denken Sie auf alle Fälle daran, dass dies reguläre Ausdrücke sind. Falls der Ausdruck zum Beispiel auf das Ende eines Nroff-Abschnitts passen soll, der mit der Zeile

  .fi

endet, benutzen Sie .fi nicht als endboundary, weil es auf »[fi]nden« passt, was vermutlich nicht das ist, was sie erwarten. Das korrekte endboundary ist in diesem Fall: ^\.fi$.

Falls das Addendum nicht dort landet, wo Sie es erwartet haben, versuchen Sie das Argument -vv an die Werkzeuge zu übergeben, so dass sie erklären, was sie beim Platzieren des Addendums tun.

Ein ausführlicheres Beispiel

Originaldokument (POD-formatiert):

 |=head1 BESCHREIBUNG
 |
 |dummy - Ein Platzhalterprogramm
 |
 |=head1 AUTOR
 |
 |mich

Dann wird das folgende Addendum sicherstellen, dass ein Abschnitt (auf Französisch) über den Übersetzer an das Ende der Datei hinzugefügt wird (auf Französisch heißt »ÜBERSETZER« »TRADUCTEUR« und »moi« heißt »mich«).

 |PO4A-HEADER:mode=after;position=AUTEUR;beginboundary=^=head
 |
 |=head1 TRADUCTEUR
 |
 |moi

Um Ihr Addendum vor dem AUTOR einzufügen, verwenden Sie die folgende Kopfzeile:

 PO4A-HEADER:mode=after;position=NOM;beginboundary=^=head1

Dies funktioniert, da die nächste auf das beginboundary /^=head1/ passende Zeile nach dem Abschnitt »BESCHREIBUNG« (übersetzt zu »NOM« auf Französisch) diejenige ist, die die Autoren deklariert. Daher wird das Addendum zwischen beide Abschnitte gelegt.

HWOTO: Wie erfolgt alles dies in einem Programmaufruf?¶

Die Benutzung von Po4a erweist sich für Benutzer als ein wenig fehleranfällig, da Sie zwei unterschiedliche Programme in der richtigen Reihenfolge aufrufen müssen (po4a-updatepo und dann po4a-translate), von denen jedes mehr als drei Argumente benötigt. Zudem war es schwer, mit diesem System nur eine PO-Datei für all Ihre Dokumente zu benutzen, wenn mehr als ein Format benutzt wurde.

Das Programm po4a(1) wurde entworfen, um diese Schwierigkeiten zu lösen. Sobald Ihr Projekt auf dieses System umgestellt wurde, schreiben Sie eine einfache Konfigurationdatei, die erklärt, wo Ihre Übersetzungsdateien (PO und POT) liegen, wo Ihre Originaldokumente liegen, deren Formate und wohin ihre Übersetzungen platziert werden sollen.

Wird po4a(1) für diese Datei aufgerufen, wird sichergestellt, dass die PO-Dateien mit dem Original synchronisiert werden und dass das übersetzte Dokument ordentlich erzeugt wird. Gewiss möchten Sie dieses Programm zwei Mal aufrufen: Einmal vor der Bearbeitung der PO-Datei, um sie zu aktualisieren, und einmal danach, um ein vollständig aktualisiertes übersetztes Dokument zu erhalten. Sie müssen sich aber nur eine Befehlszeile merken.

HOWTO: Wie wird Po4a angepasst?¶

Po4a-Module haben Optionen (mit der Option -o angegeben), die benutzt werden können, um das Verhalten des Moduls zu ändern.

Es ist außerdem möglich, ein Modul oder neue/abgeleitete/veränderte Module anzupassen, indem ein Modul in lib/Locale/Po4a/ abgelegt und dem durch die PERLLIB- oder PERL5LIB-Umgebung angegebenen Pfad lib hinzugefügt wird. Zum Beispiel:

   PERLLIB=$PWD/lib po4a --previous po4a/po4a.cfg

Hinweis: Der tatsächliche Name des Lib-Verzeichnisses ist nicht von Bedeutung.

Was steckt dahinter?¶

Die Po4a-Architektur ist objektorientiert (in Perl. Ist das nicht schön?). Der übliche Vorfahr zu allen Auswertungsklassen nennt sich TransTractor. Dieser merkwürdige Name ist der Tatsache zu verdanken, dass er gleichzeitig für das Übersetzen des Dokuments und das Extrahieren von Zeichenketten zuständig ist.

Förmlicher ausgedrückt nimmt es ein Dokument zum Übersetzen plus eine PO-Datei, die die Übersetzungen enthält, als Eingabe, während es zwei getrennte Ausgaben erzeugt: Eine weitere PO-Datei (die das Ergebnis des Extrahierens übersetzbarer Zeichenketten vom Eingabedokument ist) und einem übersetzen Dokument (mit der gleichen Struktur, wie der aus der Eingabe, bei der aber alle übersetzbaren Zeichenketten durch den Inhalt der Eingabe-PO-Datei ersetzt wurden). Hier eine grafische Darstellung davon:

 Eingabedokument -- \                             /---> Ausgabedokument
                     \      TransTractor::       /       (übersetzt)
                      +-->--   parse()  --------+
                     /                           \
 Eingabe-PO-Datei---/                             \---> Ausgabe-PO-Datei
                                                          (extrahiert)

Dieser kleine Knochen ist der Kern der Po4a-Architektur. Falls Sie die Eingabe-PO-Datei und das Ausgabedokument weglassen, erhalten Sie po4a-gettextize. Falls Sie beide Eingaben bereitstellen und die Ausgabe-PO-Datei nicht beachten, erhalten Sie po4a-translate.

TransTractor::parse() ist eine virtuelle Funktion, die durch jedes Modul implementiert wird. Hier nun ein kleines Beispiel, um zu zeigen, wie es funktioniert. Es wertet eine Liste von Absätzen aus, von denen jeder mit <p> beginnt.

  1 sub parse {
  2   PARAGRAPH: while (1) {
  3     $my ($paragraph,$pararef,$line,$lref)=("","","","");
  4     $my $first=1;
  5     while (($line,$lref)=$document->shiftline() && defined($line)) {
  6       if ($line =~ m/<p>/ && !$first--; ) {
  7         $document->unshiftline($line,$lref);
  8
  9         $paragraph =~ s/^<p>//s;
 10         $document->pushline("<p>".$document->translate($paragraph,$pararef));
 11
 12         next PARAGRAPH;
 13       } else {
 14         $paragraph .= $line;
 15         $pararef = $lref unless(length($pararef));
 16       }
 17     }
 18     return; # Keine definierte Zeile erhalten? Ende der Eingabedatei.
 19   }
 20 }

In Zeile sechs taucht <p> zum zweiten Mal auf. Dies signalisiert den nächsten Absatz. Daher sollte daher die gerade erhaltene Zeile zurück in das Originaldokument (Zeile sieben) ablegt und die soweit gebauten Absätze in die Ausgaben verschoben werden. Nachdem das führende <p> in Zeile neun entfernt wurde, wird die Verbindung dieser Markierung mit der Übersetzung des restlichen Absatzes verschoben.

Diese translate()-Funktion ist richtig toll. Sie schiebt ihre Argumente in die Ausgabe-PO-Datei (Extrahierung) und gibt ihre Übersetzung so zurück, wie sie in der Eingabe-PO-Datei vorgefunden wurde (Übersetzung). Da sie als Teil des Arguments von pushline() verwandt wird, landet diese Übersetzung im Ausgabedokument.

Ist das nicht toll? Es ist möglich, ein vollständiges Po4a-Modul in weniger als 20 Zeilen zu bauen, wenn das Format einfach genug ist …

Sie können unter Locale::Po4a::TransTractor(3pm) mehr darüber erfahren.

Gettextisierung: Wie funktioniert das?¶

Die Idee hierbei ist, das Originaldokument und seine Übersetzung zu nehmen und zu sagen, dass die Nte übersetzte Zeichenkette der Übersetzung die Übersetzung der Nten extrahierten Zeichenkette des Originals ist. Damit das funktioniert, müssen sich beide Dateien die exakt gleiche Struktur teilen. Falls die Dateien zum Beispiel die folgende Struktur haben, ist es sehr unwahrscheinlich, dass die vierte Zeichenkette der Übersetzung (vom Typ »Kapitel«) die Übersetzung der vierten Zeichenkette des Originals (vom Typ »Absatz«) ist.

    Original         Übersetzung
  Kapitel            Kapitel
    Absatz             Absatz
    Absatz             Absatz
    Absatz           Kapitel
  Kapitel              Absatz
    Absatz             Absatz

Dafür werden Po4a-Parser sowohl für das Original als auch für die Übersetzungsdateien zum Extrahieren der PO-Dateien benutzt. Dann wird eine dritte PO-Datei gebaut, deren Zeichenketten von der zweiten als Übersetzung der Zeichenketten der ersten genommen werden. Um zu prüfen, ob die zusammengefügten Zeichenketten tatsächlich die Übersetzung der jeweils anderen sind, sollten Dokumenten-Parser in Po4a Informationen über den syntaktischen Typ der extrahierten Zeichenketten im Dokument setzen (alle existierenden tun das, Ihres sollte das ebenfalls tun). Dann wird diese Information benutzt, um sicherzustellen, dass beide Dokumente die gleiche Syntax haben. Im vorhergehenden Beispiel würde es ermöglichen, festzustellen, dass Zeichenkette vier im einen Fall ein Absatz und im anderen Fall eine Kapitelüberschrift ist und dieses Problem melden.

Theoretisch wäre es möglich, das Problem festzustellen und die Dateien nachher neu zu synchronisieren (genauso wie es diff tut). Aber es ist nicht klar, was mit den wenigen Zeichenketten geschehen soll, bevor sie asynchron werden und es würde manchmal zu schlechten Ergebnissen führen. Dies ist der Grund, weshalb aktuelle Implementierungen nicht versuchen, etwas neu zu synchronisieren und lautstark fehlschlagen, wenn etwas schiefgeht, was manuelle Änderungen an Dateien erfordert, um das Problem zu lösen.

Sogar mit diesen Vorsichtsmaßnahmen können hier sehr einfach Dinge schiefgehen. Daher werden alle Übersetzungen, die auf diese Weise entstehen, als »fuzzy« (unscharf) markiert, um sicherzustellen, dass der Übersetzer sie aufarbeitet und prüft.

Addendum: Wie funktioniert es?¶

Gut, das hier ist ziemlich leicht. Das übersetzte Dokument wird nicht direkt auf die Platte geschrieben, sondern im Speicher gehalten, bis alle Addenda angewandt wurden. Die hier beteiligten Algorithmen sind eher unkompliziert. Es wird nach einer Zeile gesucht, die zum regulären Positionsausdruck passt und falls mode=before ist, wird das Addendum davor eingefügt. Wenn nicht, wird die nächste zur Abschnittsgrenze passende Zeile gesucht und das Addendum nach dieser Zeile eingefügt, falls es ein endboundary ist oder vor dieser Zeile, falls es ein beginboundary ist.

Warum ist jeder Absatz getrennt zu übersetzen?¶

Ja, in Po4a wird jeder Absatz getrennt übersetzt (tatsächlich entscheidet dies jedes Modul, aber alle existierenden Module tun dies und Ihres sollte das auch tun). Es gibt zwei Hauptvorteile für dieses Herangehen:

• Wenn die technischen Teile des Dokuments nicht sichtbar sind, kann der Übersetzer nicht daran herumbasteln. Je weniger Markierungen der Übersetzer vorgesetzt bekommt, um so weniger Fehler kann er machen.
• Das Zerschneiden des Dokuments hilft beim Isolieren der Änderungen am Originaldokument. Wenn das Original verändert wurde, wird es durch diesen Prozess vereinfacht, herauszufinden, welche Teile der Übersetzung aktualisiert werden müssen.

Sogar mit diesen Vorteilen mögen einige Leute den Gedanken nicht, jeden Absatz einzeln zu übersetzen. Hier einige Antworten auf deren Befürchtungen:

• Diese Herangehensweise erwies sich im KDE-Projekt als erfolgreich und ermöglichte dort Leuten die größte bekannte Sammlung übersetzter und aktueller Dokumentation.
• Die Übersetzer können weiterhin den Kontext zum Übersetzen benutzen, da die Zeichenketten in der PO-Datei in der gleichen Reihenfolge wie im Originaldokument stehen. Nacheinander zu übersetzen ist daher eher vergleichbar, ob Sie Po4a verwenden oder nicht. Und auf jeden Fall bleibt die beste Möglichkeit, den Kontext zu erhalten, das Dokument in ein druckbares Format umzuwandeln, da die Fassungen mit Textformatierungen nach Auffassung des Verfassers nicht wirklich lesbar sind.
• Diese Herangehensweise ist diejenige, die von professionellen Übersetzern angewandt wird. Es stimmt, dass die etwas andere Ziele als Open-Source-Übersetzer verfolgen. Die Wartung ist zum Beispiel meist weniger kritisch für sie, da der Inhalt sich seltener ändert.

Warum wird nicht auf Satzebene (oder darunter) unterteilt?¶

Professionelle Übersetzerwerkzeuge unterteilen das Dokument machmal auf Satzebene, um die Wiederverwendbarkeit vorhergehender Übersetzungen zu maximieren und ihre Verarbeitung zu beschleunigen. Das Problem ist, dass der gleiche Satz mehrere Übersetzungen haben könnte, je nach Kontext.

Absätze sind definitionsgemäß länger als Sätze. Das wird hoffentlich sicherstellen, dass der gleiche Absatz, wenn er in zwei Dokumenten vorkommt, die gleiche Bedeutung (und Übersetzung) hat, ohne in jedem Fall den Kontext zu beachten.

Unterteilen in kleinere Teile als einen Satz wäre sehr schlecht. Es wäre etwas zu umfangreich, hier zu erklären warum, aber interessierte Leser können beispielsweise die Handbuchseite Locale::Maketext::TPJ13(3pm) lesen (die der Perl-Dokumentation beigefügt ist). Kurz gesagt, hat jede Sprache ihre besonderen syntaktischen Regeln und es gibt keine Möglichkeit, Sätze durch angesammelte Teile von Sätzen für alle existierenden Sprachen zu bilden (oder gar für fünf der zehn meistgesprochenen, oder sogar weniger).

Warum wird das Original nicht der Übersetzung als Kommentar (oder auf andere Art) mitgegeben?¶

Auf den ersten Blick schien Gettext nicht für alle Arten von Übersetzungen geeignet zu sein. Es scheint zum Beispiel nicht an Debconf angepasst zu sein, die Schnittstelle, die alle Debian-Pakete für ihr Zusammenspiel mit dem Anwender während der Installtion nutzen. In diesem Fall waren die Texte schön klein (ein Dutzend Zeilen für jedes Paket) und es war schwierig, die Übersetzung in eine Spezialdatei abzulegen, da sie vor der Paketinstallation verfügbar sein müssen.

Daher haben sich die Debconf-Entwickler entschieden, eine andere Lösung zu implementieren, bei der Übersetzungen in die gleiche Datei wie das Original platziert werden. Dies ist recht ansprechend. Jemand könnte dies zum Beispiel sogar für XML wollen, dies würde dann ungefähr so aussehen:

 <section>
  <title lang="en">Mein Titel</title>
  <title lang="fr">Mon titre</title>
  <para>
   <text lang="en">Mein Text.</text>
   <text lang="fr">Mon texte.</text>
  </para>
 </section>

Aber es war dadurch so problematisch, dass nun eine PO-basierte Herangehensweise benutzt wird. Nur das Original kann in der Datei bearbeitet werden und die Übersetzung muss in PO-Dateien erfolgen, die von der Master-Schablone extrahiert wurden (und zur Kompilierungzeit des Pakets zurück platziert werden). Das alte System wurde wegen mehrerer Probleme missbilligt:

• Verwaltungsprobleme

  Falls mehrere Übersetzer gleichzeitig ein Patch bereitstellen, ist es schwierig, sie zusammenzufügen.

  Wie möchten Sie Änderungen im Original ermitteln, die auf die Übersetzungen angewandt werden? Um Diff zu benutzen, müssen sie vermerken, welche Version des Originals Sie übersetzt haben. D.h. Sie benötigen in Ihrer Datei eine PO-Datei. ;)

• Kodierungsprobleme

  Diese Lösung ist umsetzbar, wenn nur europäische Sprachen beteiligt sind, aber die Einführung von Koreanisch, Russisch und/oder Arabisch erschwert das Szenario. UTF könnte eine Lösung sein, aber es gibt immer noch Probleme damit.

  Außerdem sind solche Probleme schwer feststellbar (d.h. nur koreanische Leser werden bemerken, dass die Kodierung von Koreanisch kaputt ist [aufgrund des russischen Übersetzers]).

Gettext löst all diese Probleme gleichzeitig.

Aber Gettext wurde nicht für diese Verwendung entworfen!¶

Das stimmt, allerdings kam bisher niemand mit einer besseren Lösung. Die einzige bekannte Alternative ist die manuelle Übersetzung mit all den Verwaltungsproblemen.

Was ist mit den anderen Übersetzungswerkzeugen für Dokumentation, die Gettext benutzen?¶

Soweit mir bekannt, gibt es nur zwei davon:

poxml

Dies ist das durch KDE-Leute entwickelte Werkzeug, um DocBook-XML zu handhaben. Soweit bekannt, war es das erste Programm zum Extrahieren von Zeichenketten aus der Dokumentation in PO-Dateien und um sie nach dem Übersetzen wieder einzuspeisen.

Es kann nur XML und eine spezielle DTD handhaben. Der Verfasser ist ziemlich unglücklich mit der Handhabung von Listen, die in einer großen Msgid enden. Wenn die Liste groß wird, wird es schwerer, das große Stück zu verkleinern.

po-debiandoc

Dieses von Denis Barbier erstellte Programm ist so eine Art Vorläufer des Po4a-SGML-Moduls, wodurch ersteres mehr oder weniger missbilligt ist. Wie der Name sagt, handhabt es nur die DebianDoc-DTD, die mehr oder weniger eine missbilligte DTD ist.

Die Hauptvorteile von Po4a demgegenüber sind die Erleichterung beim Hinzufügen zusätzlichen Inhalts (was dort sogar schlechter ist) und die Fähigkeit, Gettext zu verwenden.

Entwickler über Übersetzung schulen¶

Wenn Sie versuchen, Dokumentationen oder Programme zu übersetzen, sehen Sie sich drei Arten von Problemen gegenüber; linguistische (nicht jeder spricht zwei Sprachen), technische (der Grund, weshalb Po4a existiert) und beziehungsartige/menschliche. Nicht alle Entwickler verstehen die Notwendigkeit von Übersetzungszeug. Sogar wenn sie entgegenkommend sind, könnten Sie ignorieren, wie Übersetzern die Arbeit erleichtert wird. Um dabei zu helfen, bringt Po4a ein Menge Dokumentation mit, auf die Bezug genommen werden kann.

Ein weiterer wichtiger Punkt ist, dass jede übersetzte Datei mit einem kurzen Kommentar beginnt, der angibt, um was für eine Datei es sich handelt und wie sie benutzt wird. Dies sollte den armen Entwicklern helfen, die mit tonneweisen Dateien in unterschiedlichen Sprachen überschüttet werden, die sie kaum sprechen können und hilft ihnen, korrekt damit umzugehen.

Im Po4a-Projekt sind übersetzte Dateien keine Quelldateien mehr. Da SGMl-Dateien üblicherweise Quelldateien sind, ist die ein einfacher Fehler. Daher haben alle vorhandenen Dateien diese Kopfzeilen:

 |       *****************************************************
 |       *           GENERATED FILE, DO NOT EDIT             * 
 |       * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION *
 |       *****************************************************
 |
 | This file was generated by po4a-translate(1). Do not store it (in VCS,
 | for example), but store the PO file used as source file by po4a-translate. 
 |
 | In fact, consider this as a binary, and the PO file as a regular source file:
 | If the PO gets lost, keeping this translation up-to-date will be harder ;)

Ebenso müssen die normalen PO-Dateien von Gettext nur in das Verzeichnis po/ kopiert werden. Aber dies ist nicht der Fall bei denen, die durch Po4a manipuliert wurden. Das Hauptrisiko hier ist, dass ein Entwickler die existierende Übersetzung dieses Programms mit der Übersetzung seiner Dokumentation löscht. (Beides kann nicht in der gleichen PO-Datei gespeichert werden, weil die Programme zur Installation ihrer Dokumentation als eine mo-Datei benötigen, während die Dokumentation ihre Übersetzung nur zur Zeit der Kompilierung benötigt.) Daher enthalten die PO-Dateien, die vom Module Po-debiandoc erzeugt wurden folgende Kopfzeilen:

 #
 #  ADVISES TO DEVELOPERS:
 #    - you do not need to manually edit POT or PO files.
 #    - this file contains the translation of your debconf templates.
 #      Do not replace the translation of your program with this !!
 #        (or your translators will get very upset)
 #
 #  ADVISES TO TRANSLATORS:
 #    If you are not familiar with the PO format, gettext documentation 
 #     is worth reading, especially sections dedicated to this format.
 #    For example, run:
 #         info -n '(gettext)PO Files'
 #         info -n '(gettext)Header Entry'
 #
 #    Some information specific to po-debconf are available at
 #            /usr/share/doc/po-debconf/README-trans
 #         or http://www.debian.org/intl/l10n/po-debconf/README-trans
 #

ZUSAMMENFASSUNG der Vorteile der Gettext-basierten Herangehensweise¶

• Die Übersetzungen werden nicht zusammen mit dem Original gespeichert, wodurch es möglich wird, festzustellen, ob Übersetzungen nicht mehr aktuell sind.
• Die Übersetzungen werden jeweils in separaten Dateien gespeichert, was verhindert, dass sich Übersetzer unterschiedlicher Sprachen, sowohl beim Senden des Patches als auch auf der Ebene des Dateikodierung, stören.
• Es basiert intern auf Gettext (Po4a bietet aber eine sehr einfache Schnittstelle, so dass Sie die Interna nicht verstehen müssen, um es zu benutzen). Auf diese Art muss das Rad nicht neu erfunden werden und aufgrund ihrer weiten Verbreitung kann davon ausgegangen werden, dass diese Werkzeuge mehr oder weniger fehlerfrei sind.
• Für den Endanwender hat sich nichts geändert (außer der Tatsache, dass Übersetzungen hoffentlich besser gepflegt werden). Die resultierende Dokumentationsdatei, die verteilt wird, ist exakt dieselbe.
• Es ist nicht nötig, dass Übersetzer eine neue Dateisyntax lernen und ihr bevorzugter PO-Editor (wie der PO-Modus von Emacs, Lokalize oder Gtranslator) wird gut funktionieren.
• Gettext bietet eine einfache Möglichkeit, Statistiken darüber zu erhalten, was erledigt ist, was überprüft und aktualisiert werden sollte und was noch zu erledigen ist. Einige Beispiele können unter den folgenden Adressen gefunden werden:

   - http://kv-53.narod.ru/kaider1.png
   - http://www.debian.org/intl/l10n/
      

Aber nicht alles ist rosig und diese Herangehensweise hat auch einige Nachteile, die bewältigt werden müssen.

• Addenda sind … auf den ersten Blick merkwürdig.
• Sie können den übersetzten Text nicht nach Ihren Präferenzen anpassen, wie das Aufteilen eines Absatzes hier und das Zusammensetzen zwei anderer dort. Aber, falls es in einem gewissen Sinn ein Problem mit dem Original gibt, sollte es sowieso als Fehler gemeldet werden.
• Sogar mit der einfachen Oberfläche bleibt es ein neues Werkzeug, das Leute lernen müssen.

  Es wäre traumhaft, wenn jemand Po4a in Gtranslator oder Lokalize einbinden würde. Wenn eine SGML-Datei geöffnet wird, werden die Zeichenketten automatisch extrahiert. Wenn sie gespeichert wird, kann eine übersetzte SGML-Datei auf die Platte geschrieben werden. Falls es fertiggebracht wird, ein MS-Word-Modul™ (oder zumindest RTF) zu erstellen, können es sogar professionelle Übersetzer nutzen.